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Abstract 


This document describes protocol options for conveying objects that 
have been protected using the Cryptographic Message Syntax (CMS) and 
Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1 
over an X.400 message transfer system. 


1. Introduction 


The techniques described in the Cryptographic Message Syntax [CMS] 
specification and message specifications can reasonably be 
transported via a variety of electronic mail systems. This 
specification defines the options and values necessary to enable 
interoperable transport of S/MIME messages over an X.400 system. 


This document describes a mechanism for using CMS objects as the 
message content of X.400 messages in a native X.400 environment. 
This means that gateways or other functions that expect to deal with 
IPMS, such as those specified in [MIXER] and [BODYMAP], cannot do 
anything with these messages. Note that cooperating S/MIME agents 
must support common forms of message content in order to achieve 
interoperability. 


Definition of gateway services to support relay of CMS object between 
X.400 and SMTP environments is beyond the scope of this document. 


Hoffman & Bonatti Standards Track [Page 1] 


RFC 3855 Transporting S/MIME Objects in X.400 July 2004 


1.1. Terminology 


The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 
and "MAY" in this document are to be interpreted as described in BCP 
14, RFC 2119 [MUSTSHOULD]. 


1.2. Definitions 
For the purposes of this document, the following definitions apply. 


ASN.1: Abstract Syntax Notation One, as defined in ISO/IEC 8824. 


Object Identifier (OID): A globally unique identifier value 
consisting of a sequence of integer values assigned through 
distributed registration as specified by ISO/IEC 8824. 


Transfer Encoding: A reversible transformation made on data so 8-bit 
or binary data may be sent via a channel that only transmits 7-bit 
data. 


1.3. Compatibility with Existing S/MIME Implementations 


It is a goal of this document to, if possible, maintain backward 
compatibility with existing X.400 implementations that employ S/MIME 
v3.1 wrappers. 


2. S/MIME Packaging 
2.1. The X.400 Message Structure 


This section reviews the X.400 message format. An X.400 message has 
two parts, the envelope and the content, as described in X.402 
[X.400]: 


Envelope -- An information object whose composition varies from one 
transmittal step to another and that variously identifies the 
message’s originator and potential recipients, documents its 
previous conveyance and directs its subsequent conveyance by the 
Message Transfer System (MTS), and characterizes its content. 


Content -- The content is the piece of information that the 
originating User Agent wants to be delivered to one or more 
recipients. The MTS neither examines nor modifies the content, 
except for conversion, during its conveyance of the message. MTS 
conversion is not applicable to the scenario of this document 
because such conversion is incompatible with CMS protection 
mechanisms. 
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One piece of information borne by the envelope identifies the type of 
the content. The content type is an identifier (an ASN.1 OID or 
Integer) that denotes the syntax and semantics of the content 
overall. This identifier enables the MTS to determine the message’s 
deliverability to particular users, and enables User Agents and 
Message Stores to interpret and process the content. 


Some X.400 content types further refine the structure of content as a 
set of heading elements and body parts. An example of this is the 
Interpersonal Messaging System (IPMS). The IPMS content structure is 
able to convey zero or more arbitrary body parts each identified by 
the body part type. The body part type is an ASN.1 OID or Integer 
that denotes the syntax and semantics of the body part in question. 


2.2. Carrying S/MIME as X.400 Content 


When transporting a CMS-protected message in X.400, the preferred 
approach (except as discussed in section 2.3 below) is to convey the 
object as X.400 message content. This section describes how S/MIME 
CMS objects are conveyed as the content part of X.400 messages. This 
mechanism is suitable for transport of CMS-protected messages 
regardless of the mail content that has been encapsulated. 


Implementations MUST include the CMS object in the content field of 
the X.400 message. 


If the CMS object is covered by an outer MIME wrapper, the content- 
type field of the Pl envelope MUST be set to the following CMS- 
defined value: 


id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us (840) 
rsadsi (113549) pkcs(1) pkcs7(7) 1 } 


If the CMS object is not covered by an outer MIME wrapper, the 
content-type field of the P1 envelope MUST be set to the following 
CMS-defined value: 


id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body (2) 
us (840) rsadsi (113549) pkcs(1) pkcs-9(9) smime (16) 
content-types(1) 6} 
2.2.1. Carrying Plaintext MIME objects as X.400 Content 


When transporting a plaintext MIME object in X.400, the preferred 
approach is to convey the object as X.400 message content. The 
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content-type field of the P1 envelope MUST be set to the following 
CMS-defined value: 


id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us (840) 
rsadsi (113549) pkcs(1) pkcs7(7) 1 } 


2.3. Carrying S/MIME as IPMS Body Parts 


Under some circumstances S/MIME CMS-protected messages can be 
conveyed within select body parts of the content. Implementations 
generally SHOULD NOT embed CMS objects within X.400 body parts, but 
should instead convey them as content as described in section 2.2. 
Nevertheless, one notable exception is necessary for the case of 
forwarding. 


In instances when CMS objects are forwarded as part of a message 
forwarding function, use of a body part is necessary. When 
forwarding a CMS object in an IPMS or IPMS-compatible body part, 
implementations MUST use the content-body-part as formally defined by 
[X.400], as shown below for reference. 


content-body-part {ExtendedContentType:content-type} 
EXTENDED-BODY-PART-TYPE ::= { 
PARAMETERS {ForwardedContentParameters IDENTIFIED BY 
{id-ep-content -- concatenated with content-type -- }}, 
DATA {Content IDENTIFIED BY 
{id-et-content -- concatenated with content-type -- }} } 


ForwardedContentParameters ::= SET { 
delivery-time [0] MessageDeliveryTime OPTIONAL, 
delivery-envelope [1] OtherMessageDeliveryFields OPTIONAL, 
mts-identifier [2] MessageDeliveryIdentifier OPTIONAL } 


id-ep-content {joint-iso-itu-t(2) mhs(6) ipms (1) ep(11) 17} 


id-et-content {joint-iso-itu-t(2) mhs(6) ipms (1) et(4) 17} 

The implementation MUST copy the CMS object to be forwarded into the 
Content field of the content-body-part. The direct-reference field 
of the body part MUST include the OID formed by the concatenation of 
the id-et-content value and the following CMS-defined value. 


id-ct-contentInfo OBJECT IDENTIFIER ::= 
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs (1) 
pkcs-9(9) smime (16) content-types(1) 6} 


For example, to forward any CMS object the DATA component of the body 
part would be identified by { 2 61 4 17 1 2 840 113549 19 1616}. 


Hoffman & Bonatti Standards Track [Page 4] 


RFC 3855 Transporting S/MIME Objects in X.400 July 2004 


The ForwardedContentParameters are optional and MAY be supported at 
the discretion of the implementor. The OID value id-et-content MAY 
also be included in the original-encoded-information-types field of 
the X.400 message envelope at the discretion of the sending S/MIME 

agent. 


In this instance, the content-type field of the P1 envelope MUST be 
set to the value associate with the forwarding content (e.g., integer 
22 for IPMS). 


2.4. Transfer Encoding 


According to various S/MIME specifications for message wrapping, CMS 
objects MAY optionally be wrapped in MIME to dynamically support 7- 


bit transport. This outer wrapping is not required for X.400 
transport, and generally SHOULD NOT be applied in a homogeneous X.400 
environment. Heterogeneous mail systems or other factors MAY require 


the presence of this outer MIME wrapper 
2.5. Encoded Information Type Indication 


In [MSG], the application/pkcs7-mime content type and optional 
"smime-type" parameter are used to convey details about the security 
applied (signed or enveloped) along with information about the 
contained content. This may aid receiving S/MIME implementations in 
correctly processing the secured content. Additional values of 
smime-type are defined in [ESS]. In an X.400 transport environment, 
MIME typing is not available. Therefore the equivalent semantic is 
conveyed using the Encoded Information Types (EITs). The EITs are 
conveyed in the original-encoded-information-types field of the X.400 
message envelope. This memo defines the following smime-types. 
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smime-type 
CMS protection type 


enveloped-data 
EnvelopedData 


signed-data 
SignedData 


certs-only 
SignedData 


| 

| 

| 

| 

| 

| 

| signed-receipt 
| SignedData 

| 

| enveloped-x400 
| EnvelopedData 
| 

| 

| 

| 

| 


signed-x400 
SignedData 


compressed-data 
CompressedData 


ng S/MIME Objects in X.400 


EIT Value (OID) 
Inner Content 


id-eit-envelopedData 
Data 


id-eit-signedData 
Data 


id-eit-certsOnly 
empty (zero-length content) 


id-eit-signedReceipt 
Receipt 


id-eit-envelopedx400 
X.400 content 


id-eit-signedx400 
X.400 content 


id-eit-compressedData 
RFC 3274 compression wrapper 


July 2004 


Sending agents SHOULD include the appropriate S/MIME EIT OID value. 
Receiving agents SHOULD recognize S/MIME OID values in the EITs 


field, 
procedures. 


and process the message appropriately according to local 


In order that consistency can be obtained in future S/MIME EIT 


assignments, 
assigning new EIT values. 


correspond to assigned smime-type values on a one-to-one basis. 
S/MIME EIT 


the following guidelines should be followed when 


Values assigned for S/MIME EITs should 


restrictions of section 3.2.2 of [MSG] therefore apply. 
values may coexist with other EIT values intended to further qualify 
the makeup of the protected content. 
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2.5.1. Enveloped Data 


The enveloped data EIT indicates that the X.400 content field 
contains a MIME type that has been protected by the CMS enveloped- 
data content type in accordance with [MSG]. The resulting enveloped 
data CMS content is conveyed in accordance with section 2.2. This 
EIT should be indicated by the following OID value: 


id-eit-envelopedData OBJECT IDENTIFIER ::= 
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs (1) 
pkcs-9(9) smime (16) id-eit (10) id-eit-envelopedData(1) } 


2.5.2. Signed Data 


The signed data EIT indicates that the X.400 content field contains a 
MIME type that has been protected by the CMS signed-data content type 
in accordance with [MSG]. The resulting signed data CMS content is 
conveyed in accordance with section 2.2. This EIT should be 
indicated by the following OID value: 


id-eit-signedData OBJECT IDENTIFIER ::= 
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs (1) 
pkcs-9(9) smime(16) id-eit (10) id-eit-signedData(2) } 


2.5.3. Certs Only 


The certs-only message is used to transport certificates and/or CRLs, 
such as in response to a registration request. This is described in 
[CERT31]. The certs-only message consists of a single instance of 
CMS content of type signed-data. The encapContentInfo eContent field 
MUST be absent and signerInfos field MUST be empty. The resulting 
certs-only CMS content is conveyed in accordance with section 2.2. 
This EIT should be indicated by the following OID value: 


id-eit-certsOnly OBJECT IDENTIFIER ::= 
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs (1) 
pkcs-9(9) smime (16) id-eit (10) id-eit-certsOnly(3) } 


2.5.4. Signed Receipt 


The signed receipt EIT indicates that the X.400 content field 
contains a Receipt content that has been protected by the CMS 
signed-data content type in accordance with [ESS]. The resulting CMS 
signed-data content is conveyed in accordance with section 2.2. This 
EIT should be indicated by the following OID value: 
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id-eit-signedReceipt OBJECT IDENTIFIER ::= 
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs (1) 
pkcs-9(9) smime (16) id-eit (10) id-eit-signedReceipt (4) } 


2.5.5. Enveloped X.400 


The enveloped X.400 EIT indicates that the X.400 content field 
contains X.400 content that has been protected by the CMS enveloped- 
data content type in accordance with [X400WRAP]. The resulting 
enveloped X.400 CMS content is conveyed in accordance with section 
2.2. This EIT should be indicated by the following OID value: 


id-eit-envelopedx400 OBJECT IDENTIFIER ::= 
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs (1) 
pkcs-9(9) smime (16) id-eit (10) id-eit-envelopedx400(5) } 


2.5.6. Signed X.400 


The signed X.400 EIT indicates that the X.400 content field contains 
X.400 content that has been protected by the CMS signed-data content 
type in accordance with [X400WRAP]. The resulting signed X.400 CMS 
content is conveyed in accordance with section 2.2. This EIT should 
be indicated by the following OID value: 


id-eit-signedX400 OBJECT IDENTIFIER ::= 
{ iso(1) member-body (2) us(840) rsadsi(113549) pkcs (1) 
pkcs-9(9) smime (16) id-eit (10) id-eit-signedXx400 (6) } 


2.5.7. Compressed Data 


The compressed data EIT indicates that the X.400 content field 
contains a another type that has been compressed by the compressed- 
data content type in accordance with [COMPRESS]. The resulting CMS 
content is conveyed in accordance with section 2.2. This EIT should 
be indicated by the following OID value: 


id-eit-compressedData OBJECT IDENTIFIER ::= 
{ iso(1) member-body (2) us(840) rsadsi(113549) pkcs (1) 
pkcs-9(9) smime (16) id-eit (10) id-eit-compressedData(7) } 


2.6. Interaction with X.400 Elements of Service 


Care should be taken in the selection of X.400 services to be used in 
conjunction with CMS objects. Services affecting conversion of the 
content, expansion of Distribution Lists (DLs), and message 
redirection can interact badly with services provided by the 
"EnvelopedData" and "SignedData" CMS content types. 
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2.6.1. MTS Conversion Services 


MTS conversion is not applicable to the scenario of this document 
because such conversion is incompatible with CMS protection 
mechanisms. X.400 systems that implement conversion services should 
generally be unable to attempt conversion of CMS content types 
because those types do not conform to X.420 structure rules. 
Nevertheless, when transporting CMS objects within an X.400 
environment, the Conversion Prohibition service SHOULD be selected. 


2.6.2. Message Redirection Services 


X.400 message redirection services can have an indirect impact on the 
application of the CMS "EnvelopedData" content type. Several 
different forms of redirection are possible in X.400, including: 


- Originator Requested Alternate Recipient (ORAR) 
- Alternate Recipient Assignment 
- Redirection of Incoming Messages 


In addition, any auto-forwarding services that are not security-aware 
may share the same problem. An auto-forwarding implementation that 
removes the EnvelopedData and reapplies it for the forwarded 
recipient is not affected by this problem. The normal case is that 
the private key is not available when the human user is not present, 
thus decryption is not possible. However, if the private key is 
present, forwarding can be used instead. 


When the "EnvelopedData" content type is used to protect message 
contents, an instance of RecipientInfo is needed for each recipient 
and alternate recipient in order to ensure the desired access to the 
message. A RecipientInfo for the originator is a good practice just 
in case the MTS returns the whole message. 


In the event that ORAR is used, the originator is aware of the 
identity of the alternate recipient and SHOULD include a 
corresponding RecipientInfo element. For other forms of redirection 
(including non-security-aware auto-forwarding) the alternate 
recipient must either have access to the intended recipient’s keys 
(not recommended) or must relay the message to the intended recipient 
by other means. 


2.6.3. DL Expansion 


X.400 DLs can have an indirect impact on the application of the CMS 
"EnvelopedData" content type. When the "EnvelopedData" content type 
is used to protect message contents, an instance of RecipientiInfo is 
needed for each recipient in order to ensure the desired access to 
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the message. Messages to a DL would typically include only a single 
RecipientInfo associated with the DL. Unlike Mail Lists (MLs) 
described in [ESS], however, X.400 DLs are not generally security- 
aware and do not regenerate RecipientInfo elements for the DL 
members. It is recommended that a security-aware ML conforming to 
[ESS] be used in preference to X.400 DLs. When transporting CMS 
objects within an X.400 environment, the DL Expansion Prohibited 
service SHOULD be selected. 


3. Security Considerations 
This specification introduces no new security concerns to the CMS or 
S/MIME models. Security issues are identified in section 5 of [MSG], 
section 6 of [ESS] and the Security Considerations section of [CMS]. 
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